29章 統合

qst_exe.icon

Integration

プログラムのmergeとか、結合テストのことだろうか

システムをどういう流れで開発していくか

小規模なプロジェクトでは、午前中にいくつかのクラスを1つにまとめることを指すかもしれないし、大規模なプロジェクトでは、数週間から数か月を費やして複数のプログラムを1つにまとめることを指すかもしれない。

29.1 統合手法の重要性

ワシントン大学のフットボールスタジアムの増築部分が崩壊した例(完成時の強度は問題なかったが、建設の順序が悪い例)

統合をきちんとするといいことがたくさん

欠陥がすぐに見つかる、減る

品質が高くなる

工数が減る

何だかシステムテストの存在感のない「いとこ」を盛んに持ち上げているみたいだが、その重要性にもかかわらず見過ごされているという事実こそ、統合に1章を割り当てた理由である。

29.2 統合の頻度ーフェーズ型とインクリメンタル型

29.2.1 フェーズ型の統合

1. 単体開発(各クラスの設計、コーディング、テスト、デバッグ)

2. システム統合(全部まとめて)

3. システム逆統合(システム全体のテストとデバッグ)

問題点

複数のクラスを初めてシステムにまとめたときに新しい問題が表面化し、その原因がどこにあるかわからない点

またの名をビッグバン統合

フェーズ型の統合は極めて小さなプログラムにおいて最適

具体的にはプログラムにクラスが2,3個しか含まれない場合

29.2.2 インクリメンタル型の統合

プログラムを1つ書いてはテスト、結合を繰り返していく統合

1. システムの最小機能部分の開発

2. 1つのクラスの設計、コーディング、テスト、デバッグを行う

3. 新しいクラスを骨組みに組み込み、テスト、デバッグを行う

29.2.3 インクリメンタル型の統合の利点

エラーを簡単に突き止めることができる

プロジェクトの成功が早期に決まる

進行状況が把握しやすくなる

顧客との関係が良くなる

システムの各部分が完全にテストされる

より短いスケジュールでシステムを構築できる

29.3 インクリメンタル統合戦略

29.3.1 トップダウン統合

システム階層の最上位から開発する

Javaのmain()メソッドを含むクラス、WindowsプログラミングのWinMain()など

システム制御ロジックを早い段階でテストできる

部分的に動作するプログラムを組むことができる

下位レベルの設計の詳細の完成を待って作業することができる

システムインターフェイスのテストが最後になってしまう

大量のスタブが必要

純粋なトップダウン統合は行わずに、部分的にトップダウン統合を行う事が多い

29.3.2 ボトムアップ統合

トップダウン統合の逆

システムの上位インターフェイスの組み込みが一番最後になる

最初に設計が完了しておく必要がある

29.3.3 サンドイッチ統合

最上位レベルの業務オブジェクトクラスと最下位のユーティリティクラスを先に作成し、中間層を最後に統合する

29.3.4 リスク指向統合

実装リスクが高いクラスから実装して順次統合していく手法

29.3.5 機能指向統合

機能単位で統合を行う

スタブが不要

機能追加毎に機能性がよくなる

オブジェクト指向設計と相性がよい

29.3.6 T字型統合

システム設計の問題点を洗い出すような統合

29.3.7 インクリメンタル型の統合手法のまとめ

ヒューリスティックな手法なので、これらを参考に独自の方法を打ち立てる必要がある

29.4 デイリービルドとスモークテスト

毎日ビルドする

進行状況にもよるけど、毎日ビルドできるものなのか

ビルドに失敗していないか検査する

ビルドに失敗したときにちゃんと対応できるかな

毎日スモークテストする

スモークテストをしない場合にはデイリービルドはあまり意味がない

スモークテストを最新の状態に保つ

システムの進行具合に応じて更新されること

デイリービルドとスモークテストを自動化する

CIがあるからだいぶ簡単になってそう

ビルドグループを設ける

ビルドは毎日しなくてもよいが、統合をしなくて良いわけではない

システムにコードを追加する前にスモークテストを義務付ける

ビルドを追加するコードの保管場所を作成する

GitとGitHubのタグ/リリース機能で解決しそう

ビルドが失敗した場合のペナルティを設ける

ビルド失敗時には最優先でその対応をする

ビルドは午前中にリリースする

予期せぬトラブルでの残業やトラブルが解消できないままの状態がなくなる

切迫した状況下でもビルドとスモークテストを行う

29.4.1 デイリービルドを使用できるプロジェクトの種類

大きなプロジェクトほどデイリービルドが有効

29.4.2 連続的な統合

連続的とは言っても「少なくとも毎日」というくらいのレベル